Injecting ConfigMap and Secret Data Into Pods and Containers

You’ve seen how to imperatively and declaratively create ConfigMap objects and populate them with data. Now let’s see how to get that data into applications running in containers.

There are three main ways to inject ConfigMap data into a container:

• As environment variables
• As arguments to container startup commands
• As files in a volume

Let’s look at each.

ConfigMaps and environment variables#

A common way to get ConfigMap data into a container is via environment variables. You create the ConfigMap, then you map its entries into environment variables in the container section of a Pod template. When the container is started, the environment variables appear in the container as standard Linux or Windows environment variables.

The figure below shows this:

You already have a ConfigMap, called multimap, that has two values:

• given=Nigel
• family=Poulton

The following Pod manifest deploys a single container that creates two environment variables in the container.

• FIRSTNAME: maps to the given entry in the multimap ConfigMap
• LASTNAME: aps to the family entry in the multimap ConfigMap

When the Pod is scheduled and the container started, FIRSTNAME and LASTNAME will be created as standard Linux environment variables inside the container. These can then be used by applications running in the container.

The following commands will deploy the Pod from the envpod.yml file and then list environment variables that include the name string in their name – this will list the firstname and lastname variables. You’ll see that they are populated with the values from the multimap ConfigMap.

The output will be:

Using the kubectl exec command:

The output will be:

A drawback to using ConfigMaps with environment variables is that environment variables are static. This means that any updates you make to the values in the ConfigMap will not be reflected in running containers. For example, if you update the given and family values in the ConfigMap, environment variables in existing containers will not get the updates.

ConfigMaps and container startup commands#

The concept of using ConfigMaps with container startup commands is simple. The high level looks like this. It’s possible to specify a startup command for a container, and you can customize that startup command with variables. Let’s look at a simple example.

The following Pod template (the part of a YAML manifest that defines a Pod and its containers) defines a single container, called args1. The container is based on the busybox image and runs the /bin/sh command outlined on line 5.

If you look closely at the startup command, you’ll see that it references two variables: FIRSTNAME and LASTNAME. Each of these is defined in the env: section, directly below the startup command.

• FIRSTNAME is based on the given entry in the multimap ConfigMap.
• LASTNAME is based on the family entry in the same ConfigMap.

The relationship is shown in the figure below:

Running a Pod based on the previous YAML will print “First name Nigel last name Poulton” to the container’s log file. You can see the logs of the container with the command, ＄ kubectl logs <pod-name> -c args1.

Describing the Pod will yield the following lines describing the environment of the Pod.

Using ConfigMaps with container startup commands suffers from the same limitations as using them with environment variables – updates to entries in the map will not be reflected in running containers.

ConfigMaps and volumes#

Using ConfigMaps with volumes is the most flexible option. You can reference entire configuration files as well as make updates to the ConfigMap and have them reflected in running containers. This means you can make changes to entries in a ConfigMap after you’ve deployed a container, and those changes will be seen in the container and available for running applications.

The high level process for exposing ConfigMap data via a volume looks like this:

1. Create the ConfigMap.
2. Create a ConfigMap volume in the Pod template.
3. Mount the ConfigMap volume into the container.
4. Entries in the ConfigMap will appear in the container as individual files.

This process is shown in the figure below:

You still have the multimap ConfigMap with two values.

• given=Nigel
• family=Poulton

The following YAML creates a Pod, called cmvol, with the following configuration:

• spec.volumes creates a volume, called volmap, based on the multimap ConfigMap
• spec.containers.volumeMounts mounts the volmap volume to /etc/name

Let’s go through these steps in a little more detail.

The spec.volumes block creates a special type of volume, called a ConfigMap volume. The volume is called volmap and is based on the multimap ConfigMap. This means that the volume will be populated with the entries stored in the data block of the ConfigMap. In this example, the volume will have two files: given and family. The given file will have the contents Nigel, and the family file will have the contents Poulton.

The spec.containers block mounts the volmap volume into the container at /etc/name. This means that two files will appear in the container as:

• /etc/name/given
• /etc/name/family

The following commands deploy the container (from the cmpod.yml manifest):

The output will be:

Then run a kubectl exec command to list the files in the /etc/name/ directory.

The output will be: